---
id: index
sidebar_position: 1
---
# 概述
## 微服务架构的演进过程
### 最早的系统架构设计：单体架构
![](./img/单体架构.png)
* 优点：开发、部署、上线非常简单。
* 缺点：代码耦合严重，牵一发而动全身。
### 垂直应用架构
单体架构的升级改造，是一种不好的架构，现在已经淘汰<br/>
* 优点：服务、部署中立，水平扩展容易。
* 缺点：搭建复杂，服务之间关系错综复杂，维护困难。
![](./img/垂直应用架构.png)
### SOA架构
垂直应用架构的升级改进：SOA架构。<br/>
![](./img/SOA架构.png)
### 微服务架构
![](./img/微服务架构.png)
### 微服务架构需要遵循的原则
* 职责独立：每个微服务只做自己功能范围内的事，微服务之间的依赖链不要过长
![](./img/职责独立.png)
* 使用熔断器实现快速的故障容错和线程隔离，例如Hystrix、Sentinel。
* 通过网关代理微服务请求，网关是微服务架构对外暴露的唯一入口。
![](./img/网关代理微服务请求.png)
* 确保微服务API变更后能够向后兼容。
### 微服务能够带来的收益
* 单个的微服务，可以选择一门擅长的语言去开发，扩展性强。微服务之间通过 Rest 实现通信，通过 Rest 实现注册。
* 对于整个应用而言，代码不再耦合，不会出现大量的冲突。
* 微服务可以重用，应用发布时间可控性更强。
* 通过故障隔离，让错误在微服务中降级，不会影响到整个应用（或其他服务）。
